Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-106581: Fix two bugs in the code generator's copy optimization #108380

Merged
merged 5 commits into from
Aug 24, 2023

Conversation

gvanrossum
Copy link
Member

@gvanrossum gvanrossum commented Aug 23, 2023

When replacing matched pairs of push/pop (poke/peek), I was matching up the last poke in the previous "manager" with the wrong peek in the new one, causing some copying opportunities to be missed.

Fixing this revealed a more serious bug where we could end up skipping the copy of an 'unused' poke to a used peek, leaving the variable uninitialized. The fix for this required me to keep track of the original StackItems in the CopyEffect object, and use that to reconstruct the source when copying from 'unused'.

The net result so far is that this found two redundant initializations.

I was comparing the last preceding poke with the *last* peek,
rather than the *first* peek.

Unfortunately this bug obscured another bug, which I have yet to fix:
When the last preceding poke is UNUSED, the first peek disappears,
leaving the variable unassigned.
Rename CopyEffect to CopyItem.
Change CopyItem to contain StackItems instead of StackEffects.
Update those StackItems when adjusting the manager higher or lower.
Assert that those StackItems' offsets are equivalent.
@gvanrossum
Copy link
Member Author

I apologize, when using this to split CALL_BOUND_METHOD_EXACT_ARGS I found there are more things wrong with it. So I added another commit. This mainly looks for cases of the form copy(a, unused) followed by copy(unused, b) and changes the latter into copy(a, b). (The former is effectively a no-op already.) Right now this has only a minor effect (it removes one more redundant variable load from the stack) but when splitting CALL_BOUND_METHOD_EXACT_ARGS it is of the utmost importance. However, I don't want to put that split in this same PR.

Copy link
Member

@iritkatriel iritkatriel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor tweaks.

Tools/cases_generator/stacking.py Show resolved Hide resolved
Tools/cases_generator/stacking.py Outdated Show resolved Hide resolved
(I had different code in one of the branches during debugging. :-)

Co-authored-by: Irit Katriel <[email protected]>
@gvanrossum gvanrossum enabled auto-merge (squash) August 24, 2023 18:34
@gvanrossum gvanrossum merged commit 88941d6 into python:main Aug 24, 2023
17 checks passed
@gvanrossum gvanrossum deleted the fix-stacking-bug branch August 24, 2023 20:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants